Current microcontrollers (MCUs) often support two or more “boot modes”, where the controller starts up using a particular boot process associated with one or more memory buses and/or one or more peripheral buses. For microcontrollers that contain on-chip flash memory, the boot control mechanism is used to select at least one alternate boot method to the flash memory boot. For example, RS-232 or USB boot may be supported by the processor for remote or peripheral booting, whereby a bootloader is downloaded to the microcontroller over the peripheral bus. A common usage of the scenario is “blank flashing”, whereby a new micro-controller and/or memory device in a newly manufactured product must be programmed for the first time. The flash memory of the microcontroller is typically blank, so the peripheral boot process is used to affect initial programming.
Some microcontrollers may offer a choice of peripheral boot modes, such as RS-232, USB, I2C, SPI, etc. Additionally, some microcontrollers with external memory interfaces may offer a choice of memory boot modes corresponding to the different memory interfaces. Upon microcontroller reset, the controller knows what memory device to boot from based on the selected boot mode.
It is well-known in the art that one or more input pins to the microcontroller may be dedicated for the purpose of boot control. The microcontroller, upon reset, samples these “boot control pins” for an electrical “signature” and selects the boot mode accordingly. Typically, the boot mode selection is defined by a table that is defined in the microcontroller technical literature and implemented in the ROM code or initialization logic of the microcontroller. In the most trivial example, a single boot selection line may be used, where, for example, a “1” logic level may specify boot from internal flash memory and a “0” logic level may specify boot from USB. Additional boot lines may be defined as needed by the microcontroller developers to create an arbitrarily-large number of combinations, where for “n” lines the combination of choices has a maximum of 2n.
This approach becomes problematic for more complex microcontrollers or processors that have a higher number of boot modes and hence a higher number of boot control lines, because additional I/O lines must be used for this purpose which renders certain pin/ball/signal pads unavailable for other purposes. In some instances, the boot control lines may be re-purposed for other uses post-reset, but in many cases this is difficult, not possible, or requires external multiplexing circuitry. Other techniques may be used to reduce pin count such as analog inputs, which may support more than 1 bit per input line. In U.S. Pat. No. 8,200,954, Murawski et al. teaches of a sampling technique used to detect multiple states per boot pin, allowing a larger number of boot modes with a reduced pin count.
It is well-known in the art to design an embedded device containing a microcontroller or processor to allow for the selection of at least two boot modes: a default boot mode used if no explicit boot selection action is taken, and at least one alternate boot mode which is selected by a specific, intentional action. Returning to the previous example, the single boot selection line may be pulled-up to supply (Vcc) to assert a default value of 1 (external memory boot). This is accomplished by the use of a pull-up resistor on the circuit board. The boot control line may be routed to a printed circuit board (PCB) test point, an external connection, or to other dedicated logic where such connectivity may conditionally assert a logic 0 by grounding the line. Under such specific action, the microcontroller, upon reset, would select an alternate boot mode (USB remote booting). In practice this alternate boot mode would be used in the product's factory (the “product” being an embedded device comprising said microcontroller). Some product manufacturers may limit the assertion of this line to select an alternate boot mode to the factory, while other manufacturers may allow assertion after the product is fielded (e.g. for in-field upgrade of software). This is a decision of the product manufacturer. Again, it is noted that a MCU may employ an arbitrarily-sized set of boot control lines.
The existing approaches thus have limitations. As discussed above, boot control lines use I/O lines that may be needed for other purposes. For blank flashing a product, board-level access is required, or alternately a custom interface, custom connector, or custom cable may be needed to assert the necessary signal. Board-level access may further require a custom factory fixture for the printed circuit board. Additionally, the existing approaches may be susceptible to usage by an unauthorized person. Some manufacturers do not desire their products to be alterable in the field, or they want upgrade operation limited to authorized service personnel.
Accordingly, there is a need for a system and method for selecting boot configuration in a more reliable manner that overcomes the aforementioned issues.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. For example, the processor element shown in the various figures may typically operate with any of various memory types not shown in the figures, including RAM, ROM, EEPROM, flash memory, and such memory types may be internal to the processor element or external to the processor element.